Configure Security

The security configuration of the HSM and some processing parameters are set by the CS (Configure Security) console command; the settings can be examined by the QS (Query Security) console command.  The HSM must be offline. See the HSM 8000 Console Reference Manual for details of these commands.

The parameters that can be set are:

·         PIN length – This is the length of the PIN to be stored as an encrypted PIN under the LMK. The “encrypted PIN” is one character greater than the length of the PIN. The HSM needs to know the maximum length of PIN used as the “encrypted PIN”.

·         Echo - If the answer to this question is Yes then passwords and other secret values are displayed on the console as entered.  Characters can be hidden by using ‘^’ prior to entering the component or key.  HAVING THIS ENABLED IS A SECURITY HAZARD.

·         Atalla ZMK variant support - For interoperation with Atalla systems.  This enables the optional Atalla variants within commands.  Any console command providing key support will prompt for an Atalla variant.  Selection has no effect on host commands, Atalla variants can be supplied with any appropriate command regardless of this setting.

·         Racal or Australian transaction key - Transaction key schemes are techniques whereby data-encrypting keys change with each transaction in a manner that cannot be followed by a third party.  The HSM supports three variants of transaction key: Racal, Australian (AS2805) and DUKPT.  There are command conflicts between the Racal and Australian scheme so only one can be selected

·         User storage key length - This is the length of the keys stored in user storage; it can be single, double or triple length.  The number of keys that can be stored depends upon this setting.

·         Enable single-DES - This parameter is only valid if ZMK length is double. If enabled, it prevents the use of single-length DES keys.

·         Select clear PINs - This enables the clear PIN support command ‘NG.’ Authorized mode is a requirement for these commands to be processed by a host application.  THIS IS A SECURITY RISK UNLESS PRECAUTIONS ARE TAKEN AT THE HOST.

·         Enable ZMK translate command - This enables the ‘BY’ command that allows the translation of Zone Master Keys from under another Zone Master Key.  Authorized mode is required for this command to process within a host application.  THE AVAILABILITY OF THIS COMMAND IS A SIGNIFICANT SECURITY RISK.

·         Enable X9.17 for import - This enables support for the ANSI X9.17 mechanism for key import. When being imported, each key of double or triple length is encrypted separately using the Electronic Code Book (ECB) mode of encryption.  This is a lower security option but is the only supported standard method for interoperation between systems.

·         Enable X9.17 for export - Similar to the previous item, but used when exporting keys.

·         Solicitation batch size - A method supported by the HSM to enable customers to self-select their own PINs is to use Solicitation mailers. This is a turnaround form that is sent to the cardholder. The cardholder records the PIN selection on the form and returns it to the issuer. The mailer data consists of the cardholder name and address and a reference number (an encrypted account number). As a security measure, the form returned to the issuer contains only the reference number and the PIN selection. A batch process is used to process these requests when returned. For security reasons a minimum size for the batch can be set - this parameter.  The maximum value varies dependent upon the communications option and firmware release.

·         ZMK length - The length of the Zone Master Key; single or double.  This is a backwards-compatible mode to enable the switching between 16H and 32H for ZMKs.  With this release the length of the key is identified by the first character.  Therefore single is the normal setting.

·         PIN encryption algorithm - This selects the PIN encryption algorithm to be used when encrypted PINs are stored by the card issuer.  The options are A – Visa method or B – Higher security Thales method. The Visa method is backward-compatible with the RG6000 range of HSMs.

·         Card/Password Authorisation - This option selects the method of authenticating security officers requesting a security state change. The Authorised State is a condition the HSM can be placed in for sensitive data processing.  This authorised mode is required when input functions at the console or host use clear text data such as key components or unencrypted pins. Authorised mode can be used in both Online and Offline host states and requires the authorising officers to invoke the higher security level. Before the authorised state can be set the authorising officers need to be verified by the HSM. Officer verification is done by checking either a Smartcard and PIN or a password (16 alphanumeric characters.)  If the Password option is not set when the LMK is created, the password option will not be available as no password is created and stored with the LMK components.

·         Card issuer password - This option enables Thales to change the card issuer password for LMK and authorising officer Smartcards.  If the password has been changed you will be advised when new cards are delivered. Special care must be taken that no key is inadvertently struck, placing a character in this field.  If this setting is changed, it will not be possible to format the Smartcards using the ‘FC’ command.

·         Encrypted/Plaintext decimalisation table - This option determines if the decimalisation table will be encrypted or in plain text. The option will be set for encrypted, however to allow for backward compatability plaintext decimalisation tables can be selected. It is recommended that encrypted tables are used whenever possible

·   Enable decimalisation table checks - The values in the decimalisation tables, used for deriving and verifying PIN offset values, are normally restricted to provide additional security by rejecting values which are potentially insecure. This can cause problems where existing tables fail the checks, so for backward compatibility this parameter allows the restrictions to be disabled.


Example:

Secure> CS <Return>

PIN length [4-12]: 4 <Return>

Echo [oN/ofF]: F <Return>

Atalla ZMK variant support [oN/ofF]: F <Return>

Racal or Australian transaction key? [R/A]: R <Return>

User storage key length [S/D/T]: T <Return>

 

LMKs must be erased before remaining parameters can be set.

Erase LMKs? [Y/N]: Y <Return>

 

Select clear PINs? [Y/N]: N <Return>

Enable ZMK translate command? [Y/N]: N <Return>

Enable X9.17 for import? [Y/N]: N <Return>

Enable X9.17 for export? [Y/N]: N <Return>

Solicitation batch size [1-1024]: 1024 <Return>

Enable Single DES [Y/N]: Y <Return>

Single/double length ZMKs [S/D]: S <Return>

PIN encryption algorithm [A/B]: A <Return>

Encrypted/Plaintext decimalisation table checks? [E/P]: E <Return>

Enable decimalisation table checks? [Y/N]: Y <Return>

Card/password authorisation [C/P]: C <Return>

Card issuer password [Enter = no change]: <Return>

Save SECURITY settings to smart card? [Y/N]: Y <Return>

Insert card and press ENTER: <Return>

SECURITY settings saved to the smart card.